Please stop creating new PR every time for same thing after modification

Yes, good point. I also wondered what's that about but did not checked it in details, just labelled.

Yes, I asked for separate PR fixing a typo, but it should be handled quite easily and without necessity of separate PR.

since I commited everything on develop branch, I find it difficult to separate out

Before re-creating PRs, you could ask how to do it, how to extract change from existing PR to submit as separate PR. Chances are, somebody would help you and you could have learned it for future situations that may be common during GSoC as well as during your activities on GitHub generally.

In one of other PRs, I think I suggested to add a utility converting between 1D and 2D kernels if separability is needed but 2D kernel is in hand. Just reminding the idea, in case it's a good idea. There may be better ways to solve it perhaps.

@mloskot I thought of that and after some research, I came to know that directly creating 1d kernel can be performance efficient

@lpranam The kernel conversion idea follows your #443 (comment) about re-using this function

If this function can not be reused or its outcome can not be (efficiently) converted to usable form, perhaps this function should be reworked to generate 1D or 2D kernels.

My motivation is to look for possible pattern common for number of use cases to avoid breeding too many (public!) generator functions, especially for the same filters. If we could have some neat common D-agnostic interface for kernel generators...

@laxsuryavanshi If I may, I'd suggest you to focus more on your GSoC proposal than contributing new features to GIL before GSoC starts. If you participate in GSoC, you will have time to get those features well designed and implemented. I understand you may be eager to sling PRs with new features and ideas, but this is not the best time now to propose significant features, before GSoC.
As you see, it takes time to discuss and agree on things and we don't have that time now, so your PRs will likely remain unanswered.

To summarise,

• Submit PR with your competency test if you want to have it tested and reviewed, but please keep in mind my other advice in Adding Gaussian Smoothening for images #443 (comment) (keep in mind https://www.boost.org/community/gsoc.html).
• If you are still eager to contribute something, feel free to add new test cases, help fix warnings, improve quality of existing code, etc. - submissions which are fairly easy to review and get merged independently from GSoC

I'd like to contribute to GIL even if I didn't selected cause this will only increase my programming skills.

Great and you're welcome to contribute. It's just that it usually takes time until a contributor becomes familiar with any non-trivial codebase, so her/his is capable to propose new features designed and implemented so that they fit the whole picture well.

p.s. FYI, Sir is not necessary really :)

@lpranam The kernel conversion idea follows your #443 (comment) about re-using this function

That's when @laxsuryavanshi chooses to use 2D Gaussian kernel but if he chooses to use 1D Gaussian kernel a newer implementation can generate 1d kernel faster then converting from 2d to 1d.

My motivation is to look for possible pattern common for number of use cases to avoid breeding too many (public!) generator functions, especially for the same filters. If we could have some neat common D-agnostic interface for kernel generators...

I think we can have overloads for 1D and 2D kernels which can be handy for the user.

Yes an overload taking in/out kernel parameter sounds fine.

I'm also a bit allergic to sprinkling get_* free functions over the public interface.

Even for such a simple functionality, we should be quite considerate how to shape the interface of it, also because of https://martinfowler.com/bliki/TwoHardThings.html, unless it's going to live inside namespace gil::detail, then we can afford sloppy.